At this point, I think we should start using an enum instead of a bunch of booleans.

Example:

I'll note that my code isn't properly organized, so the enum would go better elsewhere, and I didn't add the class reference in the constructor, but that should (largely) work.

Should we add a checkbox for regions as well?

We could, yes. Realistically, the "primary" caller will probably just use DisplayCheckboxes.values() instead of hardcoding the current values.

Realistically, the "primary" caller will probably just use DisplayCheckboxes.values() instead of hardcoding the current values.

Does that mean we would use the preference for the checkbox associated with the filter like ONLY_APPLICABLE.getPref() instead of using bool value? (getPref will return boolean value)

Going further on the enums, there are EnumMaps that we should start using, and the translated texts can be done via an enum field (e.g. DEPRECATED(marktr("Show deprecated tags")) + ck.setText(tr(DEPRECATED.getText())).

Moving on with the EnumMap idea, this could be done via that. For that matter, the checkbox could have a change listener that puts a boolean in an enum map.

We should probably use an enum here. We could probably reuse the one I mentioned earlier (so getMatchingPresets(String searchText, DisplayCheckboxes..., so DisplayCheckboxes is probably the wrong name; see if you can find one yourself).

how about SearchStringFilters?

That would probably work. But we have other locations where we have search strings. It might be better to have some more identifying information. Although this really depends upon where we put the enum -- if it is in its own file, it will need a much better identifier, such as PresetSearchFilter. If it remains in the TaggingPresetSelector class, then that would be part of the identifier (TaggingPresetSelector.SearchStringFilters.DEPRECATED).

I should probably mention (at this point) why I think we should start moving these booleans to an enum: easier readability. There are some other advantages, but function(bool, bool, bool, bool, bool, bool) start to get really hard to wrap your mind around. Some IDEs will give hints as to what each bool is supposed to be, but not all IDEs will.

As a specific example, GitHub doesn't show what a boolean is supposed to be for, so the reviewer/editor has to know the function definition, or go find it.

This would be the equivalent of new TaggingPresetSelector(true, true, true), which I don't think you wanted. You probably wanted to just do new TaggingPresetSelector().

When I said, "we should use an EnumMap", this is not what I was thinking. I'll go find one of the methods using this enum and see if I can hack together something there as an example.

Generally speaking, enum classes should not have a state that can change. There are exceptions, but they are exceptions.

You shouldn't need/want to do this. Importing them statically would work, or you can just use the qualified name (PresetSearchFilter.DEPREACATED_TAGS). I only saw these used in a switch statement, where they aren't needed.

You could use option.getText() here instead of calling the qualified name.

We want to have a map of option -> checkboxes, so EnumMap<PresetSearchFilter, JCheckBox> would work. Example:

final Map<PresetSearchFilter, JCheckBox> checkboxes = new EnumMap<PresetSearchFilter, JCheckBox>(PresetSearchFilter.class);
for (PresetSearchFilterOption option : options) {
    final JCheckBox box = new JCheckBox();
    box.setText(tr(option));
    box.addItemListener(e -> filterItems());
    pnChecks.add(box);
    switch (option) {
    case SEARCH_IN_TAGS:
        box.setSelected(PREF_SEARCH_IN_TAGS.get()); 
        break;
        // Do other enum values
    }
}

To avoid confusion, this should probably be textToBeTranslated or something; translatedText implies it has already been translated.

This would be the equivalent of new TaggingPresetSelector(true, true, true), which I don't think you wanted. You probably wanted to just do new TaggingPresetSelector().

This should be done via the standard Config interface or one of the Property classes.

Ideally, you would just use the same EnumMap from one of my other comments (EnumMap<PresetSearchFilter, JCheckBox>) instead.

Example: map.entrySet().stream().filter(entry -> entry.getValue().isSelected().map(Map.Entry::getKey).toArray(PresetSearchFilter[]::new).

We should probably keep the properties.

Realistically, the map can be populated with ckpreferences.computeIfAbsent(key, k -> PROPERTY.get()).

Using (and saving) the preferences lets us keep the checkbox state between application restarts.

I think we want to keep the PREFERENCE.put method calls.